Methods and systems of distributed transaction processing

ABSTRACT

A first transaction computer system and a second transaction computer system are provided. The first transaction computer system receives data transaction requests that may be routed to the second transaction computer system. The second transaction computer system attempts to match the routed data transaction request against pending data transaction requests using hidden attributes.

CROSS REFERENCE(S) TO RELATED APPLICATION(S)

This application claims priority to U.S. Provisional Application No.62/490,698, filed Apr. 27, 2017, the entire contents of which are herebyincorporated by reference. The entire contents of U.S. Publication No.2017/0004563 are also incorporated by reference.

TECHNICAL OVERVIEW

The technology described relates to distributed transaction processing.More particularly, the technology described herein relates totransaction processing that uses two different systems to selectivelymatch data transaction requests across two different sorted lists ofdata transaction requests.

INTRODUCTION

Computer systems can be programmed to handle and process datatransaction requests. Such systems can be helpful in many differenttechnical areas including, for example, automated electronic exchangecomputer systems. These systems can be configured to process millions orbillions of transaction requests per day. In these types ofenvironments, data transaction requests are stored in dual sorted lists.A computer system attempts to match newly received transaction requestswith a pending request that is on the “opposite” side of the list fromthe incoming request.

In certain instances how one or more data transaction requests areprocessed using one system (e.g., a first automated exchange) can bereliant on a state or status of an external system (e.g., anotherautomated exchange) for its processing. This presents a technicalproblem in the field of distributed transaction processing.

One possible solution to performing processing based on the distributednature of two (or more systems) is to simply mirror the states of thedifferent systems so they are always synchronized with each other.However, this type of full synchronization becomes inefficient andproblematic when the distributed systems need to operate as fast aspossible for a large amount of data transaction requests.

Thus, new techniques for how distributed systems may be constructed forhandling data transaction requests in a distributed manner are needed.

SUMMARY

In certain example embodiments, a first transaction computer system anda second transaction computer system are provided. The first transactioncomputer system receives data transaction requests that may be routed tothe second transaction computer system. The second transaction computersystem attempts to match the routed data transaction request againstpending data transaction requests using hidden attributes. In certainexamples, a constraint value, which is based on a state of an order bookof the first transaction computer system, is included in the routedmessage sent to the second transaction computer system. A datatransaction request that is pending and identified for a match by thesecond transaction computer system may be locked while confirmation ofthe match is reported back to the first transaction computer system. Aclient system associated with the pending data transaction request mayreceive match information that includes the hidden attributes (e.g. avalue, such as a price value, at which the match occurred) while theclient system associated with the received data transaction request maynot receive that information.

This Summary is provided to introduce a selection of concepts that arefurther described below in the Detailed Description. This Summary isintended neither to identify key features or essential features of theclaimed subject matter, nor to be used to limit the scope of the claimedsubject matter; rather, this Summary is intended to provide an overviewof the subject matter described in this document. Accordingly, it willbe appreciated that the above-described features are merely examples,and that other features, aspects, and advantages of the subject matterdescribed herein will become apparent from the following DetailedDescription, Figures, and Claims.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features and advantages will be better and morecompletely understood by referring to the following detailed descriptionof example non-limiting illustrative embodiments in conjunction with thedrawings of which:

FIG. 1 shows two example computer systems with different order booksthat communicate to determine matches between new and pending datatransaction requests;

FIGS. 2A-2B show a signal diagram of how data transaction requests arematched using the systems in FIG. 1 according to certain exampleembodiments; and

FIG. 3 shows an example computing device that may be used in someembodiments to implement features described herein.

DETAILED DESCRIPTION

In the following description, for purposes of explanation andnon-limitation, specific details are set forth, such as particularnodes, functional entities, techniques, protocols, etc. in order toprovide an understanding of the described technology. It will beapparent to one skilled in the art that other embodiments may bepracticed apart from the specific details described below. In otherinstances, detailed descriptions of well-known methods, devices,techniques, etc. are omitted so as not to obscure the description withunnecessary detail.

Sections are used in this Detailed Description solely in order to orientthe reader as to the general subject matter of each section; as will beseen below, the description of many features spans multiple sections,and headings should not be read as affecting the meaning of thedescription included in any section.

Overview

In certain example embodiments, a first computer system is provided thatstores two sorted lists (also referred to as a first “order book” or acentral limit order book, CLOB, herein) of received data transactionrequests (also referred to as “orders” herein). Another computer systemis provided that stores another pair of sorted lists. The second pair oflists may be referred to as a second order book or a crossrate orderbook herein.

Certain example embodiments relate to routing received data transactionrequests from a first computer system to a second computer system forprocessing thereon. In certain instances, routing to and processing bythe second computer system is recorded for a future rebate. New datatransaction requests routed to the second computer system are sent withdata (e.g., a constraint value) regarding the current state of the orderbook on the first computer system. The current state may be, forexample, the best bid and offer, BBO, of the first order book. Thesecond computer system then attempts to match the new data transactionrequest at a price that is between that BBO (e.g., the current state ofthe first order book) to pending orders that are in the second orderbook. If a match is found by the second computer system (e.g., againstother data transaction requests that are in the second order book), thenthe details of the match are sent back to the first computer system thatthen processes or executes the match. A first client computer systemthat initially submitted the new data transaction request to the firstcomputer system is then notified of the successful match. In certaininstances, the notification includes an indication that the match wasperformed against the second order book. However, the “price” of thefinal match is not reported to the first client computer system at thistime. However, a differential based on the price of the hidden match maybe stored and used to determine a rebate for an entity associated withthe first client computer system. Details of the match (including theprice of the match) may be communicated to a second client system thatoriginally submitted the data transaction request that was firstincluded in the second order book (and matched against the datatransaction request from the first client computer system).

In certain examples, the first computer system will, for newly receivedorders, 1) perform order validation for the order (e.g., including pricevalidation); 2) create and save a reference to the order in the firstcomputer system to later access that order; 3) pass the order with “lit”price information (e.g., based on the first order book) to the secondarycomputer system; 4) wait for the secondary computer system to respondwith an execution or no execution message; 5) generate executionnotification and trade confirmations (that may include an indicationthat the order was processed by the second computer system), performrisk validations, and the like. 6) if the order was not matched on thesecond computer system then the order may be processed by the firstcomputer system (e.g., a normal match process is performed); 7)notification messages may be generated and sent back to the originalorder submitting client computer.

FIG. 1 illustrates the systems used to handle the two separate orderbooks and match incoming data transaction requests to pending datatransaction requests. FIGS. 2A-2B show a signal diagram of how datatransaction requests are matched using the systems in FIG. 1 accordingto certain example embodiments. FIG. 3 shows an example computing devicethat may be used in some embodiments to implement features describedherein.

FIG. 1

FIG. 1 illustrates a primary data transaction system 100 (also referredto as system 100 herein) and a secondary data transaction system 102(also referred to as system 102 herein). In certain example embodiments,both system 100 and system 102 are separate computer systems (e.g., eachbeing a “computer”—such as that shown in FIG. 3). In certain exampleembodiments, system 100 and system 102 are different computer processesthat operate within one operating system using the same set ofprocessing resources (which may include one or more computer systems asshown in FIG. 3). In certain example embodiments, system 100 and system102 may each operate within their own virtual machine (VM) environment(e.g., a Java™ virtual machine environment). Such VMs may execute on thesame underlying computer hardware or may operate on different computerhardware. In other words, while systems 100 and 102 are separate, theymay be separated logically (executing within different process spaces ofa single computer system) and/or physically (executing on differentunderlying computer hardware) depending the specific architectural needsof the overall distributed system.

System 100 and system 102 communicate with one another via respectiveinterfaces 110 and 116. In certain example embodiments, interfaces 110and 116 may represent individual transceivers (e.g., network interfacedevice 306). In other examples, interfaces 110 and 116 may be softwarebased interfaces that allow the separately executing processes orsystems to communicate with one another. For example, system 100 maygenerate an electronic data message that includes information regardinga newly received data transaction request and send that data message tothe system 102. Such a message may be sent via a socket connection(e.g., an IP address and port number) established from interface 110 tointerface 116. Other types of communication techniques may be used suchas, for example, interprocess communication (IPC) techniques (e.g.,pipes, shared memory, message applications, and the like).

Both system 100 and system 102 operate by receiving and processing datatransaction requests (also referred to herein as orders or electronicorders for simplicity). Data transaction requests are submitted in theform of electronic data messages that include a request for acorresponding order (e.g., a data transaction request to match an orderto another pending, or future, order). The data transaction requests mayspecify a client ID that identifies the client sending the request(e.g., a company, person, etc. . . . ), an instrument ID that identifiesa particular instrument for the order (e.g., a ticker symbol oridentifier for U.S. treasury benchmarks, or the like), transaction typeID that may identify, for example, whether the request is associatedwith a sell or buy instruction, an order attribute that specifieswhether this a regular order or a hidden order, and a price value thatindicates a particular price for the order subject to the datatransaction request. In certain examples, other fields may be defined inthe electronic order and/or some may be optional.

System 100 includes a transaction request database 112 and a transactionprocessor 114. The transaction request database 112 may include dualsorted lists of data transaction requests. The lists may be stored in anin-memory data structure (e.g., a sorted list), a flat file, a databasemanagement system (DBMS), or the like. In certain instances, thetransaction request database 112 may include an order book that storesreceived orders (e.g., orders that are pending in the order book). Thetransaction request database 112 may be viewed a first “pool” (e.g., alit pool or a public pool) of data transaction requests that may beeligible for matching against incoming or received data transactionrequests.

The transaction processor 114 includes the logic (e.g., an executableprocess that performs one or more of the algorithmic steps associatedwith FIGS. 2A and 2B) for matching orders to one another. For example,when a new order is received by system 100, transaction processor 114may attempt to match the new order to a contra-side order that iscurrently in the transaction request database 112. In certain examples(as discussed in greater detail below), the transaction processor 114(or other functionality of the system 100) may route a newly receivedorder to system 102 via interfaces 110 and 116. The transactionprocessor 114 may represent a combination of hardware (e.g., amicroprocessor such as processor 302) and an executing computer program(e.g., a computer process).

System 100 may also include functionality to provide match confirmationsto client systems (e.g., consumer client system 104, provider clientsystem 106, and/or other client systems). For example, system 100 maygenerate an electronic data feed that corresponds to the current stateof the transaction requests DB 112. The electronic data feed may includeinformation on all actions that modify or update records in thetransaction requests DB 112. For example, when a newly received datatransaction request is matched against a pending data transactionrequest (e.g., a “buy” order is matched to a “sell” order), a datamessage may be generated based on that match and be sent out as part ofan electronic data feed. The data message may include informationregarding the ID (e.g., a ticker symbol) for the matched orders, theamount matched (e.g., the quantity), and/or the value at which the matchoccurred (e.g., $100).

System 102 includes transaction requests database 118 and transactionprocessor 120. Like the database in system 100, the transaction requestsdatabase 118 includes dual sorted lists of pending data transactionrequests that may also be, in certain examples, an order book (ormultiple order books—such as one for each instrument). The transactionprocessor 120 may also operate in a manner similar (or the same) totransaction processor 114 such that it may attempt to match incomingdata transaction requests (e.g., those routed from system 100) to datatransaction requests that are pending in transaction requests database118. In contrast to the order book in the transaction requests database112, the order book in database 118 may be viewed a second “pool” (e.g.,a dark pool or a private pool) of data transaction requests that may beeligible for matching against incoming or received data transactionrequests (e.g., those that are received directly at system 102 or thosedata transaction requests routed from system 100). In certain exampleembodiments, transaction request database 118 may only include datatransactions requests for certain types of clients and/or certain typesof securities or eligible instruments. For example, a data transactionrequest submitted to system 102 from provider client system 106 that isfor an instrument identifier not included in database 118 may cause thesystem 102 to generate a message that indicates the data transactionrequest has been rejected (e.g., because that type of instrument is noteligible to be added to the database 118).

In certain examples, if an instrument for a data transaction requestsubmitted from consumer client system 104 to system 100 is not eligible,but is still routed to system 102 then one of two options may be carriedout. If the data transaction request was marked as only being executableagainst database 118, an error message may be generated and returned toconsumer client system 104. If the data transaction request is eligiblefor processing against database 112 (but not database 118), then it maybe returned to system 100 for potential match processing thereon.

In certain examples, databases 112 and 118 may also include user accountinformation (e.g., accounts that are used by client systems to accessthe primary or secondary transaction systems), instrument information(e.g., information that defines which order books in databases 112 and118 that a given instrument may be eligible for). Some users may beconfigured to such that they can submit orders to systems 100, 102, orboth systems 100 and 102. In certain examples, only quote orders may beadded to the order book in database 118. In certain examples, orderssubmitted from different provider client systems to system 102 will notmatch against one another (e.g., bid and offer prices in database 118may overlap). In certain examples, a user account that is associatedwith a consumer client system may always “default” to routing ordersassociated with the user to the secondary transaction system (e.g., theuser may not need to specify that a newly submitted order use therouting technique).

One possible difference between systems 100 and 102 is that all actionsthat update or modify database 112 maybe reported over a publicelectronic data feed. Database 112 may thus be thought of as a “lit”database because its contents are publically visible (e.g., via theprovided publically available electronic data feed). However, database118 may not operate in such a manner. Instead, database 118 may storedata transaction requests that are “hidden” or “dark.” Thus, if a neworder is matched against a pending order that is in database 118, the(full) details of that match may not be made available to third parties(or even all of the counter parties to the match). Accordingly, one wayto view databases 112 and 118 is as two separate “pools” of datatransaction requests (e.g., orders)—a “lit” pool and a “dark” pool. Forthe “lit” pool actions that modify or otherwise update the order bookfor that pool are reported out over an electronic data feed to thirdparty consumers. In contrast, for the “dark” pool, similar types ofactions may not cause information to be transmitted out over anelectronic data feed. In certain examples, information regarding thedark pool may be sent out in aggregated form on a time-delay basis(e.g., every 30 minutes, every hour, at the end of the trading day, atthe end of week, month, quarter, year, etc. . . . )

System 102 may operate as a stand-alone transaction system (e.g.,without also relying on system 100). In certain example embodiments,data transaction requests may be submitted directly to system 102 thatmay then process, match, and execute such data transaction requestswithout reporting the results of the execution or match to system 100.Similarly, primary transaction system 100 may operate (e.g., receive,process, execute, and report orders) autonomously from secondarytransaction system 102.

In addition, while systems 100 and 102 may be communicatively coupled toone another, their integration may be seamless from the perspective ofconsumer client system 104 and provider client system 106. Thus, forexample, an existing transaction system (e.g., an automated electronicexchange computer system) may be modified to communicate with secondarytransaction system without any change in communication protocols or datatransaction request field requirements for consumer client systems 104.In certain examples, consumer client systems 104 may thus communicatewith a transaction system irrespective of whether or not the transactionsystem also communicates with a secondary transaction system. However,in certain examples, a flag or field may be added to the communicationprotocol for submitted data transaction requests. This field may providea client a way to communicate that it desires to have the correspondingorder (potentially) routed to a secondary transaction system.

Returning to FIG. 1, consumer client system 104 and provider clientsystem 106 are implemented on client computer systems (or other computersystems are controlled in some fashion by the “client”). Client computersystems can include personal computers, mobile devices, automatedcomputer systems, cloud-based computer systems, and the like. Generally,systems 104 and 106 may include any computer system (e.g., such as thatshown in FIG. 3) programmed to interface with systems 100 and/or 102 forthe purpose of submitting data transaction requests (e.g., orders) toeither of systems 100 and 102. In certain instances, the provider clientsystems 106 are those that are controlled or operated by so-calledmarket makers or entities that provide liquidity for a givensecurity—also terms liquidity providers (LPs). In certain instances, theconsumer client systems are those that are controlled or operated byentities that generally consume liquidity. For example, a broker that isacting on behalf of individual investors may be a liquidity consumer(LC) entity.

Consumer client system 104 is configured to communicate with system 100via interface 110. Generally, the consumer client system submits datatransaction requests (e.g., orders) that are “lit” (or will be if theyare matched against a contra-side pending order). However, as describedin connection with FIGS. 2A and 2B, there are certain instances wherethe full details of a match between orders may not be made fullyavailable.

In contrast to the consumer client system 104, provider client system106 communicates, via interface 116, with system 102 (in certaininstances system 106 may also communicate with system 100 via interface110). Generally, the provider client system 106 submits data transactionrequests (e.g., orders) that are “dark” such that if they are matchedagainst other data transaction requests (e.g., those submitted from aconsumer client system), then the full details of the match will not bereported via a public electronic data feed. In certain exampleembodiments, provider client systems may only submit quotes to system102. In other words, these data transaction requests may only be addedto the database 118 without the possibility of matching against other,pending, data transaction requests that are already stored in database118.

Example implementations of exchange computer systems that handle orderswith dark, private, or hidden attributes (e.g., the price of quantity ofthe order) are described in U.S. Publication No. 2017/0004563, theentire contents of which are hereby incorporated by reference.

The following is one example of how the systems shown in FIG. 1 mayoperate. A provider client system 106 submits a sell order of 100 @ 100to system 102. This order is stored to the transaction requests DB 118.Consumer client system 104 may then submit a buy order for 100 @ 101 tosystem 100. Upon receipt of this order, system 100 may determine thatthe order should be first routed to system 102 for potential process. Ifthis buy order is routed to system 102, the transaction processor 120may determine a matching price of 100.5 for the two orders. However, theprice of the match may not be reported via any public electronic datafeed. Instead, for example, a matching price of 101 may be reported—theprice that corresponds to the publically “lit” price of the sell ordersubmitted by the consumer client system 104.

As explained in greater detail below, while a match may be determined bythe transaction processor 120 of system 102, the details of that match(and how the match will be executed) may be transmitted and handled bysystem 100. Once the execution information is returned to the system100, then that system may be responsible for executing the “trade,”reporting trade confirmations, validating the order, and handling otherpost-trade functionality.

FIG. 2A-2B

FIGS. 2A and 2B shows a signal diagram of how data transaction requestsare matched using the systems in FIG. 1 according to certain exampleembodiments.

At 200, the provider client system 106 submits a data transactionrequest (e.g., an order) to system 102. The submitted information mayinclude data fields that include: 1) a price value, 2) a quantity value,3) an identifier (e.g., a ticker symbol), 4) the type of order (e.g.,buy or sell, or bid or offer), 5) a discretion attribute, and otherfields.

At 202, the system 102 validates the order received from the providerclient system 106. This may include validating that the price andquantity values are valid for the submitted order. If system 102determines that the order is invalid it may transmit an error message tothe provider client system 106 with details of why the order is invalid(e.g., due to an invalid quantity value or the like). On the other hand,if the order is validated it is then added to the order book 118 at step204. Once added, “order 1” (also referred to as a liquidity provider(LP) order) will remain there until it is canceled or matched against acontra-side order (e.g., that has been submitted from client system104).

In certain example embodiments, orders submitted from provider clientsystems 106 may specify a “lit” price and discretion price (e.g., thatmay be an absolute price or one that is offset from the provided litprice). In certain examples, the order may only include a discretionprice (e.g., a number of ticks) and the BBO that is maintained by system100 and/or system 102 may be used to determine the final discretionprice (e.g., final price=tick internal*number of ticks+maintained BBO).In certain examples, the same provider client system 106 may submitmultiple different orders that all rest within the order book ofdatabase 118 at different price levels (e.g., for the same instrument).

At step 206, “order 2” (also referred to as a liquidity consumer (LC)order) is submitted from the consumer client system 104 to system 100.As with order 1, order 2 is then validated at step 208. Order 2 may beone of multiple different types of orders including an immediate orcancel (IOC) order, a limit order, a market order, or the like. Incertain examples, the “price” that is used for orders submitted from aconsumer client system 104 must be a valid “lit” price (e.g., at a validtick value for a given instrument). However, in certain implementations,the price may include a hidden component (e.g., a number of validdiscretion ticks or a price at which the order may execute).

At step 210, system 100 determines if order 2 is eligible for routing tosystem 102. In certain examples, the determination and subsequentrouting occurs substantially immediately (e.g., less than 1 second orevent less than 100 microseconds).

A determination as to whether or not to route the received order tosystem 102 can be based on one or more different factors. In certainexamples, if the submitted order includes a specific flag (e.g., aNO_ROUTE flag) it will not be routed to the secondary transaction system102. In certain examples, only certain types of accounts, users, orentities may be eligible to submit orders that are eligible for routing.In certain examples, the submitted order may indicate what percentage ofthe order is eligible for matching against orders in order book 112and/or a percentage of the order that is eligible for matching againstorders that are resting in order book 118. For example, an order mayindicate that only 20% of the order is eligible for matching againstorder book 112. Accordingly, if 100% is matched against order book 118,none will be matched against order book 112. However, if 0% is matchedagainst order book 118, then only 20% of the original size of the ordermay be matched against order book 112.

In any event, at step 210, system 100 determines if order 2 is eligiblefor routing to system 102. If order 2 is not eligible for routing then aregular matching process is executed at step 212. This may includematching against pending orders that are in order book 112 and/or addingorder 2 to order book 112 (e.g., if order 2 is not an “immediate orcancel”—IOC—order). After handling the matching process at step 212, aconfirmation message and/or execution message may be transmitted toconsumer client system 104 at step 214 and the process ends at step 216(e.g., system 100 continues to wait for new orders to be received).

If, however, order 2, is eligible for routing then, at step 218,secondary order processing is carried out. The secondary orderprocessing includes creating a reference for order 2 and saving it inorder book 112 (or another part of database 112). The creation of thisreference may ensure that when a successful execution message isreturned from system 102 that the order will be properly processed bysystem 100. The reference information also provides a way for system 100to handle subsequent requests regarding order 2 that are received afterorder 2 is routed to system 102, but before it has returned from system102.

When order 2 is routed to system 102 for processing, the current bestbid and offer (BBO) value for the order book 112 may be retrieved andused as a constraint or other value when the order is processed bysystem 102. This value may include the best offer and the best bid that,as explained herein, act as constraints on how matches may be identifiedby system 102. The value included with the routed order is the current“lit” price. In other words, this constraint is the price that isvisible and at which the new order would have traded had it executedagainst order book 112. As the order book of system 100 is continuallyupdated (e.g., as new orders are added to the book), the BBO may changein accordance with the changes to the order book. Thus, other ordersthat are routed may have a different constraints based on thedynamically changing BBO. Such information may be continually updatedand/or maintained by system 100. Accordingly, the BBO may be thought ofas a dynamic value that is a function of the current state of thetransaction request DB 112 (e.g., the order book). In certain examples,the determination of the BBO may include receiving data from externalsources (e.g., other order books or exchange).

The information that is gathered at step 218 may be used to generate afurther data message that is sent to system 102. The further datamessage may include an identifier for the user (or other entity) thatsubmitted order 2, a security identifier (e.g., a ticker symbol or otheridentifier), the price included in the order details of order 2, the“lit” price of order book 112 (e.g., the current best bid and offer—BBO)or other constraint value (e.g., one that may be preset or based on someother metric), the original data transaction request, and/or otherparameters.

Note that by routing order 2 to system 102, there is a possibility thatorders received by system 100 will be executed out of order. Forexample, if consumer client system 104 submits a first order that isrouted to system 102 followed by a second order that is not routed tosystem 102, it is possible that the second order will be booked (or evenexecuted) (e.g., at step 212) before system 102 returns (e.g., if nomatch was identified) the first order to system 100 for processing. Inother words, system 100 may respond to the consumer client system 104for the second order prior to responding to the consumer client system104 for the first order. It will be appreciated that this may causeconfusion with clients that submit orders. However, as discussed hereinand in accordance with certain example embodiments, a routed order maymaintain a reference identifier that can act as a place holder in theexecution line of system 100. Thus, with such a reference, orders for agiven client may be processed in order (even if the second order isdelayed in processing due to a the first order being routed to system102).

Returning to FIG. 2A and step 220, a data message is transmitted (e.g.,via an electronic data communications network), from system 100 tosystem 102. When this further data message is received by interface 116,system 102 performs secondary match processing at 222 where a match isidentified. In particular, the transaction processor 120 attempts tofind a match using the order information of order 2 that was included inthe transmitted message sent from system 100 against orders that arepending in order book 118.

If no match is found (not shown in FIG. 2B), then an unable to trade ornon-execution message is returned to system 100 and order 2 may beprocessed normally (e.g., as described in connection with step 212).

As described above, order 2 may include a data field that indicates thatonly a certain portion (e.g., a percentage) of order 2 is to be matchedusing the process in step 212 (or 222) (e.g., against the regular orderbook). If order 2 indicates that no percentage of the order is eligiblefor matching against order book 118, then an unable to execute ornon-execution message may be returned to consumer client system 104.

In step 222, a match between order 2 (the LC order) and order 1 (the LPorder) that is pending in order book 118 is identified. Once a potentialmatch is identified (between orders 1 and 2 in this case), thenexecution information is sent back to system 100 at 224 and order 1 islocked within order book 118 at 223. During the time period between 223(the locking of order 1) and 231 (release of order 1), order 1 cannot beacted upon or modified. For example, other orders will not be able tomatch against it and the LP will not be able to modify, cancel, orupdate the order while it is locked.

In certain example embodiments, the transaction processor 120 will neverexecute or identify a match between orders at a price that is worse thatthe price at which order 2 was submitted. In certain examples, thetransaction processor 120 will only execute a match if it is between the“top” lit prices (e.g., greater than the bid and lower than the offer ofthe BBO). In certain examples, exceptions to this type of matchingrequirement may be implemented (e.g., if there is a one-sided orderbook, if there is no lit price (such as trading just opened), etc. . . .).

In certain example embodiments, order 2 is only eligible to matchagainst a single quote at a single price (e.g., it will not match atmultiple price levels for fulfillment) from order book 118.

At step 224, transaction processor 120 generates a responsive messagethat is sent back to system 100 via interfaces 110 and 116. Theresponsive message may include the “actual” price of the match (e.g.,the hidden price at which the match occurs). Other types of informationrelated to the identified match may also be transmitted back to system100.

System 100 receives the message transmitted at 224 and then performsexecution processing at 226. Execution processing by system 100 mayinclude credit validation processing (e.g., determining if the clientassociated with order 2 has sufficient credit to execute the matchidentified by system 2). If the execution processing succeeds (e.g., ifthe credit validation does not return an error), then an executionconfirmation or acceptance message is generated at 228 and sent back tosystem 102.

At 230, system 100 generates and reports, to at least the consumerclient system 104, the public details of the match identified by thesecondary transaction system 102. In particular, the “hidden” price isnot transmitted at 230 to the consumer client system 104. Instead, thepublic price (e.g., a price at the BBO) is used for this message.However, in certain example embodiments, the message may include anindication that the match was in actuality performed using the secondaryprocessing system 102 and was thus at some (e.g., unspecified) priceother than the “public” price. For example, the message may include apublic price field of 100 with another bit field marked to “true” toindicate that that match occurred at a price between the best bid andoffer (e.g., at a hidden or private price). In certain examples, themessage to consumer client system 104 may include more detailedinformation on the actual or hidden price.

System 100 may also generate public match messages that are transmittedout via an electronic data feed to third party computer systems (e.g.,those system that are not parties to the match between orders 1 and 2).Like the message sent to consumer client system 104, this message mayalso use the “public” price of any match rather than the “private”price.

In general, system 100 provides trade confirmation and notificationfunctionality—even if the match or trade occurred (or was identified) onsystem 102. In certain examples, this may include generating tradeconfirmations for both the provider and consumer client systems. Incertain examples, this may include generating all required electronicdata feed and AFT confirmations—including guaranteed delivery of all LC,electronic data feed, and AFT confirmations. In certain examples, system100 generates trade confirmations that are sent back to system 102 fordissemination to the provider client system 106.

Returning to FIG. 2B, at 229, system 102 receives the executionconfirmation message sent at 228 from system 100 and books the executionof the match between orders 1 and 2. Then at 231, order 1 is releasedfrom the previously implemented “lock” (assuming there is any quantityleft over) to allow for other orders to match against it (or for theorder to be modified, updated, or canceled).

At 233, system 102 generates a message that includes executionnotification and trade confirmation regarding the recently matchedorders and sends it to provider client system 106. Unlike thenotification sent to the consumer client system 104, this notificationmay include the actual price at which the match occurred. Thenotification returned to provider client system 106 may also include the“lit” price (e.g., both the bid and offer) at the time of the matchbetween orders 1 and 2. In certain examples, this information isprovided to the provider client system 106, but not to the consumerclient system 104.

As part of the post-trade processing by system 100 (or system 102), thedetails of each match at step 232 may be stored. Based on this storedinformation, an accumulated data report may be generated at step 234 andtransmitted to the consumer computer system 104 (or another computersystem). The transmitted report may be delivered via e-mail to a clientcomputer system or posted to a website for a user to download. Incertain examples, the report may be formatted and transmitted as part ofan electronic data feed. The report may indicate, for example, the totalprice differential between the “reported” cost of a trade and the actualcost of the trade.

In certain examples, reports may provide a retrospective look at howorders submitted from clients have been processed by systems 100 and/or102. Reports may include determining an overall “toxicity” of the ordersthat have be processed using the techniques herein. Toxic orders (or theflow of orders from a given client) are those that tend to negativelyaffect the market. For example, orders that move the market may beconsidered toxic as opposed to those orders that follow the market.Orders that move the market in the opposite direction of its more“natural” movement may be considered toxic.

Identification of such orders is a difficult task because it isdifficult to know the “direction” that the market is heading at a givenpoint in time. Accordingly, in certain examples, the overall order flowfrom a given participant or client is aggregated over a period of timeand used to measure where the market is number of seconds (e.g., 30seconds) or minutes later from when orders for that client have beenprocessed. This data may be averaged to obtain the overall flow for thatclient for all of their orders. If the average processing for orders fora given client comes out neutral (e.g., within a predefined range) or inthe market's favor, then orders from that client may be classified asnon-toxic. However, if the data shows a client is continually obtainingbenefits in their favor (e.g., matches they achieve are better than whatcould be obtained 30 seconds after the fact) it may point to orders fromthis client as being toxic.

The following are example reports that may be generated: 1) an intra-daytrade report that is only sent out to LCs that generated trades duringthe defined interval; 2) and end of day (EOD) report that is sent to allLCs regardless of the fact if they generated trades that day or not; 3)an LC report that provides data on all activity for that liquidityconsumer. The reports may be delivered via CSV, web page, excel, PDF, orthe like.

The intra-day trade report is delivered at predefined time interval (aminimum×seconds, minutes, or hours) after a trade (e.g., 2-3 minutes,one hour, etc. . . . ). This report may be generated and emailed to anLC. The email will include the following information and include everytrade for the current date for trades older than X. The report willprovide information on potential price improvement so far. The includedfields are: 1) Time—time of the trade; 2) Trade ID—Trade referencenumber; 3) Instrument—traded security name; 4) User—User ID logged intosystem 100; 5) Volume—size of the trade; 6) Side—Buy/Sell; 7) LC TradePrice—reported trade price to LC based on lit price at the time; 8)Price improvement—expressed as $'s per $1 mm (e.g., if the PriceImprovement is 1 tick, then this field would show $5); 9) LC PotentialPrice improvement—LC price improvement share expressed as total $'s(e.g., Traded size*price improvement per $1 mm*LC price improvementshare percentage—if the trade size is $10 mm and the price improvementis $10 and the LC share percentage is 50%, this would be 10×10×0.5=$50);and 10) Running LC Potential Price improvement total for the day up tothis point expressed in total $'s (so a running total of ‘9’ above forall trades done on this specific day.

The end of day trade report will be generated for all trades for thisbusiness day and also report on current and running toxicity as of endof the day. The report will contain every trade information as perinter-day report and additionally market impact information. The reportmay include the following information: 1) Time—time of the trade; 2)Trade ID—Trade reference number; 3) Instrument—traded security name; 4)User—User ID logged into system 100; 5) Volume—size of the trade; 6)Side—Buy/Sell; 7) LC Trade Price—reported trade price to LC based on litprice at the time; 8) Price improvement—expressed as $'s per $1 mm(e.g., if the Price Improvement is 1 CR tick, then this field would show$5); 9) LC Potential Price improvement—LC price improvement shareexpressed as total $'s (e.g., traded size*price improvement per $1 mm*LCprice improvement share percentage—if the trade size is $10 mm and theprice improvement is $10 and the LC share percentage is 50%, this wouldbe 10×10×0.5=$50); 10) Running LC Potential Price improvement total forthe day up to this point expressed in total $'s (e.g., a running totalof ‘9’ above for all trades done on this specific day); 11) MarketImpact Amount—expressed as $'s per mm; 12) Market ImpactAmount—expressed in total $'s (Size*Market Impact per $1 mm); and 13)Running totals at bottom of report for LC Price Improvement share andMarket Impact Amount—expressed in total $'s.

Liquidity provider reports may also be generated and these reports maybe used internally and/or provided to the LPs. The reports may be, forexample, used to confirm that a given LP is supplying enough “good”liquidity for a given instrument.

A first report may include a market quote participation report that maybe used for an LP and/or internally. This report may be generated atEOD. The report may include the percentage of time that LP providedmarket per security/per sector per side with required minimum priceimprovement and minimum depth (notional). Each LP will be required toprovide market for minimum defined percentage of the day. Percentage oftime that LP provided market per security/per sector per side withaverage price improvement and average depth (notional).

A second report may include a market trade contribution ranking reportgenerated at EOD. This report will focus on LP and total traded volumein system 102 and how this LP percentage of the traded volume andpotentially the ranking for the LP (e.g., amongst other LPs). The reportshould be able to provide the metric for current trade and for specifiedpast X days. The report would include the following information: 1)Volume traded in system 102 for current trade date per security andtotal; 2) Volume traded in system 10 for current trade date by LP persecurity and total; 3) Current trade date ranking for LP based on tradedvolume per security and total; 4) RATV (Rolling Average Total Volume ofall transactions in U.S. Treasury OTRs by all LPs over the previous 10QTDs) for the last ten days for all securities traded in system 102; 5)RASV (Rolling Average per Security Volume of all transactions in each ofthe U.S. Treasury OTRs by all LPs over the previous 10 days) for thelast ten days per security traded in CR; 6) Number of LPs in system 102;7) LP RATV; 8) LP RATV share counted as: “RATV/Number of LPs×2”; 9) LPRATV rule violation flag; 10) LP RASV per security; 11) LP RASV shareper security counted as: “RASV/Number of LPs×4”; and 12) LP RASV ruleviolation flag.

A third report may be a EOD transaction report that contains a recap ofthe trade level detail from the trade day activity including: 1)Time—time of the trade; 2) Instrument—traded security name; 3) User—UserID logged into systems 100 or 102; 4) Trade reference; 5) Volume—size ofthe trade; 6) Side—Buy/Sell; 7) LC Trade Price—reported trade price toLC based on lit price at the time; 8) LP Trade Price—trade priceactually done in CR as reported to LP; 9) F-VWAP; 10) Marketimpact—expressed in total $'s; and 11) Running sum of market impact—$'s.

A fourth report may be an Expected Liquidity Provider Rebate Report thatis run at the end of day. This report gives a running total for QTD. Thereport may provide each LP with end of the day market impact and rebatereport with information on running overall market impact amounts in thepool and the market impact associated with their specific transactionsboth by individual security and in aggregate across nettable sectors.The report may include: 1) Instrument—traded security; 2) TotalVolume—Total system 102 traded volume per security; 3) LP Volume—LPtraded volume per security; 4) Total Market Impact per security—MarketImpact associated with trades for this specific security across system102; 5) LP Total Market Impact per security—Market Impact associatedwith trades for this LP for this specific security; 6) Total MarketImpact per sector—Market Impact associated with trades for this specificsector across system 102; 7) LP Total Market Impact per sector—MarketImpact associated with trades for this LP for this specific sector; and8) Expected LP rebate—expected LP rebate up to QTD.

A fifth report may be a LP trade analysis report (provided per LP). Thisreport may provide information regarding why the LP did not trade andmay include: 1) Report will list every trade that happened in CR pool;2) Time of trade; 3) Security; 4) Volume; 5) CR Price of trade; 6)Permitted spread at the time (bid/offer); 7) Indicator if traded by thatLP or not; and 8) If not traded by that LP then reason: a) Better priceavailable than LP, b) Competition at same price level (someone was infront), c) Size not satisfied (LP had price but not size), and d) LP didnot have quote at the time.

A sixth report may include a Detailed Market Participation report thatis provided at EOD. This report may provide a detailed break-down forthe time when the LP is quoting per security/per sector. The report mayinclude: 1) Percentage information per specified time windows and perday total; 2) Percentage for when minimum price improvement and minimumdepth is satisfied, by LP; 3) Percentage of time when minimum one sidedprice improvement is provided but minimum depth is not satisfied by LP;and 4) Percentage for when minimum depth is satisfied but minimum onesided price improvement is not provided, by LP.

A seventh report may be a market Impact report at the end of day (with arunning total for QTD). The report may provide each LP with end of theday toxicity report with information on running overall toxicity in thepool and toxicity associated with their transactions. The report mayinclude: 1) Instrument—traded security; 2) Total Volume—Total system 102traded volume per security; 3) LP Volume—LP traded volume per security;4) LP Toxicity—Toxicity associated with trades for this LP for security;5) System 102 Toxicity—Total system 102 venue toxicity for security.

The following is an example for how an entity may be rebated forparticipating in the process described in FIGS. 2A and 2B. In thefollowing scenario, the highest public bid is 100, the lowest offer is101, and an LP order is pending with system 102 with a “private” offerof 100.5. An LC order is received by system 100 with a bid of 101. Undernormal circumstances, the LC order would match against another pendingorder for 101 that is resting in the order book of system 100. However,in this case, the LC order is routed to the secondary transaction systemthat matches at 100.75 (or 100.5 in certain examples). While the matchoccurs at 100.75, the price that is reported to the consumer clientsystem 104 will be 101. The price of the actual match (e.g., 100.75) isreported to provider client system 106. In certain example embodiments,the difference between the public and private prices may be delivered toan account in bulk. In other words, when the trade is first validated anLC will “pay” the lit price, but may be rebated based on the hiddenprice. This may be accomplished by incrementing a credit account for anLC that is based on the difference between public price and the privateprice (or a portion of that difference).

Other functionality found in systems 100 and/or 102 may include thefollowing features. In certain examples, cancellation or modification oforder 2 may be blocked once order 2 is routed to system 102. Inparticular, there may be race condition that occurs when an order isrouted but still has not been finally executed. When the order is routedto system 102 it no longer “exists” in system 100. Thus, if a usersubmits an order that is routed to system 102, but sends in acancellation request before system 100 “knows” the status of that order(e.g., before it is returned by system 102), system 100 may generate andsend a message that the order is “not found.” But, once the order isreturned by system 102 to system 100, an execution message may berelayed from system 100 to consumer client system 104 indicating thatthe canceled (but not found) order has now be executed. To address thispotential problem, a reference for order 2 may be added to system 100(e.g., by being stored in database 112). Thus, when consumer clientsystem 104 submits a cancellation request, that request may be stored inassociation with the reference and system 100 may then appropriatelycancel the order when the order is returned from system 102. Forexample, when the order is returned from system 102, the request tocancel the order may be triggered upon system 100 recognizing that theorder has been returned for processing.

Another issue that may be addressed with storage of a reference isduplication of the order ID. In this scenario, a customer sends a firstorder with ID X, which is routed to system 102 by system 100. Thecustomer accidently sends a second order with the same ID. This order isnot routed, but instead is regularly processed by system 100 (e.g., atstep 212). Now there are two orders with the “same” ID—and both couldtheoretically execute. The addition of the reference to the database 112may alleviate this provide as system 100 may determine if there isanother order that is already pending with system 102.

Generally, no real-time or conflated data streams of system 102 will beprovided to external computer systems. But, in certain exampleembodiments, an internally accessible data stream regarding activity ofthe order book in database 118 may be provided. This data stream may beused so that a provider of secondary transaction system 102 can monitorand/or report on its status.

In certain example embodiments, orders that are executed or matchedusing system 102 must satisfy the following conditions: The executionprice displayed to the LC must be greater than or equal to the actualexecution price for the match plus a minimum required toxicity holdback.The shown execution price is a price that is a valid lit boundary. Theactual execution price is a quote price submitted by an LP at which thetrade is executed. The minimum required toxicity holdback may be thesmallest current fraction required to be held back for toxicitypurposes.

In certain example embodiments, the minimum required toxicity holdbackmay be zero. In certain example embodiments, the minimum requiredtoxicity holdback can be configured as a default for the whole system102, per instrument, or each user and/or LC may have their own value.Advantageously, the later of these implementations may ensure that moretoxic LCs are subject to higher hold-back rates. In certain examples,the minimum holdback may be dynamically changed (e.g., during a tradingday). In certain example embodiments, a process may be implemented tomeasure toxicity. Based on these calculations a decision may be made todynamically change the “minimum required toxicity holdback”.

FIG. 3

FIG. 3 is a block diagram of an example computing device 300 (which mayalso be referred to, for example, as a “computing device,” “computersystem,” or “computing system”) according to some embodiments. In someembodiments, the computing device 300 includes one or more of thefollowing: one or more processors 302; one or more memory devices 304;one or more network interface devices 306; one or more displayinterfaces 308; and one or more user input adapters 310. Additionally,in some embodiments, the computing device 300 is connected to orincludes a display device 312. As will explained below, these elements(e.g., the processors 302, memory devices 304, network interface devices306, display interfaces 308, user input adapters 310, display device312) are hardware devices (for example, electronic circuits orcombinations of circuits) that are configured to perform variousdifferent functions for the computing device 300.

In some embodiments, each or any of the processors 302 is or includes,for example, a single- or multi-core processor, a microprocessor (e.g.,which may be referred to as a central processing unit or CPU), a digitalsignal processor (DSP), a microprocessor in association with a DSP core,an Application Specific Integrated Circuit (ASIC), a Field ProgrammableGate Array (FPGA) circuit, or a system-on-a-chip (SOC) (e.g., anintegrated circuit that includes a CPU and other hardware componentssuch as memory, networking interfaces, and the like). And/or, in someembodiments, each or any of the processors 302 uses an instruction setarchitecture such as x86 or Advanced RISC Machine (ARM). As explainedherein, multiple computer systems may collectively form a cloud computersystem and each one of the computer systems is configured to host one ormore virtual machines (which are also referred as instances herein)

In some embodiments, each or any of the memory devices 304 is orincludes a random access memory (RAM) (such as a Dynamic RAM (DRAM) orStatic RAM (SRAM)), a flash memory (based on, e.g., NAND or NORtechnology), a hard disk, a magneto-optical medium, an optical medium,cache memory, a register (e.g., that holds instructions), or other typeof device that performs the volatile or non-volatile storage of dataand/or instructions (e.g., software that is executed on or by processors302). Memory devices 304 are examples of non-volatile computer-readablestorage media.

In some embodiments, each or any of the network interface devices 306includes one or more circuits (such as a baseband processor and/or awired or wireless transceiver), and implements layer one, layer two,and/or higher layers for one or more wired communications technologies(such as Ethernet (IEEE 802.3)) and/or wireless communicationstechnologies (such as Bluetooth, WiFi (IEEE 802.11), GSM, CDMA2000,UMTS, LTE, LTE-Advanced (LTE-A), and/or other short-range, mid-range,and/or long-range wireless communications technologies). Transceiversmay comprise circuitry for a transmitter and a receiver. The transmitterand receiver may share a common housing and may share some or all of thecircuitry in the housing to perform transmission and reception. In someembodiments, the transmitter and receiver of a transceiver may not shareany common circuitry and/or may be in the same or separate housings. Incertain example embodiments, network interfaces and/or transceivers mayallow the transmission and reception of messages and/or packets via anelectronic data communications network. For example, a packet switchednetwork (with each packet containing a header and a payload) may be usedto transmit and receive data from remove one computer (and associatedinterfaces) to another.

In some embodiments, each or any of the display interfaces 308 is orincludes one or more circuits that receive data from the processors 302,generate (e.g., via a discrete GPU, an integrated GPU, a CPU executinggraphical processing, or the like) corresponding image data based on thereceived data, and/or output (e.g., a High-Definition MultimediaInterface (HDMI), a DisplayPort Interface, a Video Graphics Array (VGA)interface, a Digital Video Interface (DVI), or the like), the generatedimage data to the display device 312, which displays the image data.Alternatively or additionally, in some embodiments, each or any of thedisplay interfaces 308 is or includes, for example, a video card, videoadapter, or graphics processing unit (GPU).

In some embodiments, each or any of the user input adapters 310 is orincludes one or more circuits that receive and process user input datafrom one or more user input devices (not shown in FIG. 3) that areincluded in, attached to, or otherwise in communication with thecomputing device 300, and that output data based on the received inputdata to the processors 302. Alternatively or additionally, in someembodiments each or any of the user input adapters 310 is or includes,for example, a PS/2 interface, a USB interface, a touchscreencontroller, or the like; and/or the user input adapters 310 facilitatesinput from user input devices (not shown in FIG. 3) such as, forexample, a keyboard, mouse, trackpad, touchscreen, etc. . . .

In some embodiments, the display device 312 may be a Liquid CrystalDisplay (LCD) display, Light Emitting Diode (LED) display, or other typeof display device. In embodiments where the display device 312 is acomponent of the computing device 300 (e.g., the computing device andthe display device are included in a unified housing), the displaydevice 312 may be a touchscreen display or non-touchscreen display. Inembodiments where the display device 312 is connected to the computingdevice 300 (e.g., is external to the computing device 300 andcommunicates with the computing device 300 via a wire and/or viawireless communication technology), the display device 312 is, forexample, an external monitor, projector, television, display screen,etc. . . .

In various embodiments, the computing device 300 includes one, or two,or three, four, or more of each or any of the above-mentioned elements(e.g., the processors 302, memory devices 304, network interface devices306, display interfaces 308, and user input adapters 310). Alternativelyor additionally, in some embodiments, the computing device 300 includesone or more of: a processing system that includes the processors 302; amemory or storage system that includes the memory devices 304; and anetwork interface system that includes the network interface devices306.

The computing device 300 may be arranged, in various embodiments, inmany different ways. As just one example, the computing device 300 maybe arranged such that the processors 302 include: a multi (orsingle)-core processor; a first network interface device (whichimplements, for example, WiFi, Bluetooth, NFC, etc. . . . ); a secondnetwork interface device that implements one or more cellularcommunication technologies (e.g., 3G, 4G LTE, CDMA, etc. . . . ); memoryor storage devices (e.g., RAM, flash memory, or a hard disk). Theprocessor, the first network interface device, the second networkinterface device, and the memory devices may be integrated as part ofthe same SOC (e.g., one integrated circuit chip). As another example,the computing device 300 may be arranged such that: the processors 302include two, three, four, five, or more multi-core processors; thenetwork interface devices 306 include a first network interface devicethat implements Ethernet and a second network interface device thatimplements WiFi and/or Bluetooth; and the memory devices 304 include aRAM and a flash memory or hard disk.

As previously noted, whenever it is described in this document that asoftware module or software process performs any action, the action isin actuality performed by underlying hardware elements according to theinstructions that comprise the software module. Consistent with theforegoing, in various embodiments, each or any combination of theconsumer client system 104, system 100, system 102, provider clientsystem 106, transaction processors 114 and 130, interfaces 110 and 116,transaction request database 112 and 118, each of which will be referredto individually for clarity as a “component” for the remainder of thisparagraph, are implemented using an example of the computing device 300of FIG. 5 (or a plurality of such devices). In such embodiments, thefollowing applies for each component: (a) the elements of the computingdevice 300 shown in FIG. 3 (i.e., the one or more processors 302, one ormore memory devices 304, one or more network interface devices 306, oneor more display interfaces 308, and one or more user input adapters310), or appropriate combinations or subsets of the foregoing) areconfigured to, adapted to, and/or programmed to implement each or anycombination of the actions, activities, or features described herein asperformed by the component and/or by any software modules describedherein as included within the component; (b) alternatively oradditionally, to the extent it is described herein that one or moresoftware modules exist within the component, in some embodiments, suchsoftware modules (as well as any data described herein as handled and/orused by the software modules) are stored in the memory devices 304(e.g., in various embodiments, in a volatile memory device such as a RAMor an instruction register and/or in a non-volatile memory device suchas a flash memory or hard disk) and all actions described herein asperformed by the software modules are performed by the processors 302 inconjunction with, as appropriate, the other elements in and/or connectedto the computing device 300 (i.e., the network interface devices 306,display interfaces 308, user input adapters 310, and/or display device312); (c) alternatively or additionally, to the extent it is describedherein that the component processes and/or otherwise handles data, insome embodiments, such data is stored in the memory devices 304 (e.g.,in some embodiments, in a volatile memory device such as a RAM and/or ina non-volatile memory device such as a flash memory or hard disk) and/oris processed/handled by the processors 302 in conjunction, asappropriate, the other elements in and/or connected to the computingdevice 300 (i.e., the network interface devices 306, display interfaces308, user input adapters 310, and/or display device 312); (d)alternatively or additionally, in some embodiments, the memory devices302 store instructions that, when executed by the processors 302, causethe processors 302 to perform, in conjunction with, as appropriate, theother elements in and/or connected to the computing device 300 (i.e.,the memory devices 304, network interface devices 306, displayinterfaces 308, user input adapters 310, and/or display device 312),each or any combination of actions described herein as performed by thecomponent and/or by any software modules described herein as includedwithin the component.

Consistent with the preceding paragraph, as one example, in anembodiment where an instance of the computing device 300 is used toimplement system 100 and/or system 102, the memory devices 304 couldload or store transaction request databases 112 and/or 118, and/or storethe data described herein as processed by transaction processors 114 and120. Processors 302 could be used to (in conjunction with appropriatelyconfigured software) to execute the transaction processors 114 and 120and the functionality associated therewith (e.g., to identify matchesbetween different data transaction requests).

The hardware configurations shown in FIG. 3 and described above areprovided as examples, and the subject matter described herein may beutilized in conjunction with a variety of different hardwarearchitectures and elements. For example: in many of the Figures in thisdocument, individual functional/action blocks are shown; in variousembodiments, the functions of those blocks may be implemented using (a)individual hardware circuits, (b) using an application specificintegrated circuit (ASIC) specifically configured to perform thedescribed functions/actions, (c) using one or more digital signalprocessors (DSPs) specifically configured to perform the describedfunctions/actions, (d) using the hardware configuration described abovewith reference to FIG. 3, (e) via other hardware arrangements,architectures, and configurations, and/or via combinations of thetechnology described in (a) through (e).

Technical Advantages of Described Subject Matter

In certain example embodiments, the techniques described herein allowfor more efficient and/or flexible match processing against for twodifferent sets of data transaction requests. In particular, datatransaction requests that are received at one system, but routed toanother, may carry with them a value that is based on a dynamicallymonitored value from the first system (e.g., the BBO). This approachallows the second system to operate based on the status of the firstsystem—without having to completely mirror the status of the firstsystem.

In certain examples, this approach also allows for selective routing ofdata transaction requests received at the first system to the secondsystem. This advantageously allows for matching to occur using theprivate attributes of the second system, but for the matches to bereported using the public attributes of the first system.

Selected Terminology

Whenever it is described in this document that a given item is presentin “some embodiments,” “various embodiments,” “certain embodiments,”“certain example embodiments, “some example embodiments,” “an exemplaryembodiment,” or whenever any other similar language is used, it shouldbe understood that the given item is present in at least one embodiment,though is not necessarily present in all embodiments. Consistent withthe foregoing, whenever it is described in this document that an action“may,” “can,” or “could” be performed, that a feature, element, orcomponent “may,” “can,” or “could” be included in or is applicable to agiven context, that a given item “may,” “can,” or “could” possess agiven attribute, or whenever any similar phrase involving the term“may,” “can,” or “could” is used, it should be understood that the givenaction, feature, element, component, attribute, etc. is present in atleast one embodiment, though is not necessarily present in allembodiments. Terms and phrases used in this document, and variationsthereof, unless otherwise expressly stated, should be construed asopen-ended rather than limiting. As examples of the foregoing: “and/or”includes any and all combinations of one or more of the associatedlisted items (e.g., a and/or b means a, b, or a and b); the singularforms “a”, “an” and “the” should be read as meaning “at least one,” “oneor more,” or the like; the term “example” is used provide examples ofthe subject under discussion, not an exhaustive or limiting listthereof; the terms “comprise” and “include” (and other conjugations andother variations thereof) specify the presence of the associated listeditems but do not preclude the presence or addition of one or more otheritems; and if an item is described as “optional,” such descriptionshould not be understood to indicate that other items are also notoptional.

As used herein, the term “non-transitory computer-readable storagemedium” includes a register, a cache memory, a ROM, a semiconductormemory device (such as a D-RAM, S-RAM, or other RAM), a magnetic mediumsuch as a flash memory, a hard disk, a magneto-optical medium, anoptical medium such as a CD-ROM, a DVD, or Blu-Ray Disc, or other typeof device for non-transitory electronic data storage. The term“non-transitory computer-readable storage medium” does not include atransitory, propagating electromagnetic signal.

Additional Applications of Described Subject Matter

Although process steps, algorithms or the like, including withoutlimitation with reference to FIGS. 1-2B, may be described or claimed ina particular sequential order, such processes may be configured to workin different orders. In other words, any sequence or order of steps thatmay be explicitly described or claimed in this document does notnecessarily indicate a requirement that the steps be performed in thatorder; rather, the steps of processes described herein may be performedin any order possible. Further, some steps may be performedsimultaneously (or in parallel) despite being described or implied asoccurring non-simultaneously (e.g., because one step is described afterthe other step). Moreover, the illustration of a process by itsdepiction in a drawing does not imply that the illustrated process isexclusive of other variations and modifications thereto, does not implythat the illustrated process or any of its steps are necessary, and doesnot imply that the illustrated process is preferred.

Although various embodiments have been shown and described in detail,the claims are not limited to any particular embodiment or example. Noneof the above description should be read as implying that any particularelement, step, range, or function is essential. All structural andfunctional equivalents to the elements of the above-describedembodiments that are known to those of ordinary skill in the art areexpressly incorporated herein by reference and are intended to beencompassed. Moreover, it is not necessary for a device or method toaddress each and every problem sought to be solved by the presentinvention, for it to be encompassed by the invention. No embodiment,feature, element, component, or step in this document is intended to bededicated to the public.

1. A distributed computer system comprising: a first transactioncomputer system that includes at least a first hardware processor, afirst memory device configured to store a dual-sorted list of pendingpublic data transaction requests, and a first transceiver; a secondtransaction computer system that includes at least a second hardwareprocessor, a second memory device configured to store at least oneprivate data transaction request, and a second transceiver; the firsthardware processor programmed to: receive, from a first client computersystem, a first data transaction request that includes a requestedpublic matching value, obtain a constraint value that is based at leastin part on a current state of the dual-sorted list, generate a routingmessage that includes the constraint value and the first datatransaction request, and transmit the routing message to the secondtransaction computer system; the second hardware processor programmedto: receive, via the second transceiver, the routing message, identify amatch, at a private matching value, between the first data transactionrequest and the private data transaction request, where the privatematching value is based on the constraint value and is different fromthe requested public matching value and the constraint value, and basedon identification of the match, transmit a match message back to thefirst transaction computer system; and the first hardware processorfurther programmed to: in response to reception of the match message,perform a process that confirms that the match between the first datatransaction request and the private data transaction request is valid,and generate and transmit, to the first client computer system, aconfirmation message that includes a public value, which is differentfrom the private matching value, at which the match occurred between thefirst data transaction request and the private data transaction request,wherein the confirmation does not include the private matching value. 2.The distributed computer system of claim 1, wherein the first hardwareprocessor is further configured to: in response to reception of thefirst data transaction request, store, to the first memory device, areference identifier that acts as a placeholder for the first datatransaction request.
 3. The distributed computer system of claim 2,wherein the first hardware processor is further configured to: receive,after the routing message is transmitted to the second transactioncomputer system and before the match message is received by the firsttransaction computer system, a cancellation or modification message thatincludes a request to cancel or modify the first data transactionrequest; store, in association with the reference identifier, a requestto cancel or modify the first data transaction request; and afterreception of the match message, trigger the stored request to cancel ormodify the first data transaction request.
 4. The distributed computersystem of claim 1, wherein the first hardware processor is furtherconfigured to: receive, from the first client computer system, a seconddata transaction request after the routing message is transmitted to thesecond transaction computer system and before the match message isreceived by the first transaction computer system, wherein the seconddata transaction request is not routed to the second transactioncomputer system; and hold match processing for the second datatransaction request until at least the match message is received by thefirst transaction computer system.
 5. The distributed computer system ofclaim 1, wherein the second hardware processor is further configured to:based on identification of the match, lock the private data transactionrequest such that it cannot be modified while locked; and in response toreception of an execution confirmation message sent by the firsthardware processor, unlock the private data transaction request.
 6. Thedistributed computer system of claim 1, wherein the second hardwareprocessor is further configured to: generate and transmit, to a secondclient computer system that is associated with the private datatransaction request, a confirmation message that includes privatematching value.
 7. The distributed computer system of claim 1, whereinthe second hardware processor is further configured to: perform aprivate matching process based on data for a second data transactionrequest received from the first transaction computer system againstpending data transaction requests that include private matchingattributes; and in response to determination that no match has beenfound for the second data transaction request, send a no match performedmessage to the first transaction computer system, wherein the firsthardware processor is further configured to: perform a matching processfor the second transaction request against the dual-sorted list toidentify at least one counter-party data transaction request to matchagainst.
 8. The distributed computer system of claim 1, wherein thesecond data transaction request includes an attribute amount thatindicates what percentage of the second data transaction is eligible formatching against the dual-sorted list, wherein an amount for theidentified match between the counter-party data transaction request andthe second data transaction request is controlled based on the attributeamount.
 9. The distributed computer system of claim 1, wherein the firsthardware processor further programmed to: after reception of the matchmessage, perform another matching process for a remainder of the firstdata transaction request not matched to the private data transactionrequest, the another matching process performed against the dual-sortedlist of pending public data transaction requests.
 10. A method ofperforming distributed transaction processing with a first transactioncomputer system that stores a dual-sorted list of pending public datatransaction requests and a second transaction computer system thatstores at least one private data transaction request, the methodcomprising: receiving, from a first client computer system and at thefirst transaction computer system, a first data transaction request thatincludes a public matching value, generating, at the first transactioncomputer system, a routing message that includes a constraint value andthe first data transaction request, wherein the constraint value isbased at least in part on a current state of the dual-sorted list, andtransmitting, using the first transaction computer system, the routingmessage to the second transaction computer system; receiving, at thesecond transaction computer system, the routing message, identifying amatch, at the second transaction computer system, between the first datatransaction request and the private data transaction request, whereinthe match is determined at a private matching value that is differentfrom the requested public matching value and the constraint value, basedon identification of the match, transmitting a match message back to thefirst transaction computer system from the second transaction computersystem; in response to reception of the match message at the firsttransaction computer system, perform a process that confirms that thematch between the first data transaction request and the private datatransaction request is still valid; and based on confirmation that thematch is valid, transmitting, to the first client computer system, aconfirmation message that includes a public value, which is differentfrom the private matching value, at which the match occurred between thefirst data transaction request and the private data transaction request,wherein the confirmation does not include the private matching value.11. The method of claim 10, further comprising: in response to receptionof the first data transaction request, store, to the first memorydevice, a reference identifier that acts as a placeholder for the firstdata transaction request.
 12. The method of claim 11, furthercomprising: receiving, after the routing message is transmitted to thesecond transaction computer system and before the match message isreceived by the first transaction computer system, a cancellation ormodification message that includes a request to cancel or modify thefirst data transaction request; storing, in association with thereference identifier, a request to cancel or modify the first datatransaction request; and after reception of the match message,triggering the stored request to cancel or modify the first datatransaction request.
 13. The method of claim 10, further comprising:receiving, from the first client computer system, a second datatransaction request after the routing message is transmitted to thesecond transaction computer system and before the match message isreceived by the first transaction computer system, wherein the seconddata transaction request is not routed to the second transactioncomputer system; and holding match processing for the second datatransaction request until at least the match message is received by thefirst transaction computer system.
 14. The method of claim 10, furthercomprising: based on identification of the match, locking the privatedata transaction request such that it cannot be modified while locked;and in response to reception of an execution confirmation message sentby the first hardware processor, unlock the private data transactionrequest.
 15. The method of claim 10, further comprising: transmitting,to a second client computer system that is associated with the privatedata transaction request, a confirmation message that includes privatematching value.
 16. The method of claim 10, further comprising: afterreception of the match message, performing another matching process fora remainder of the first data transaction request not matched to theprivate data transaction request, the another matching process performedagainst the dual-sorted list of pending public data transactionrequests.
 17. The method of claim 10, wherein the second datatransaction request includes an attribute amount that indicates whatpercentage of the second data transaction is eligible for matchingagainst the dual-sorted list, wherein an amount for the identified matchbetween the counter-party data transaction request and the second datatransaction request is controlled based on the attribute amount.
 18. Anon-transitory computer readable storage medium storing instructions foruse with a distributed computer system that includes a first transactioncomputer system and a second transaction computer system, the firsttransaction computer system storing pending public data transactionrequests and the second transaction computer system storing at least oneprivate data transaction request, the stored instructions comprisinginstructions that, when executed, cause the computer system to: receive,from a first client computer system, a first data transaction requestthat includes a requested public matching value; at the firsttransaction computer system, generate a routing message that includes aconstraint value and the first data transaction request, wherein theconstraint value is based on a dynamically changing value that isderived, at least in part, from a current state of the dual-sorted list;transmit the routing message to the second transaction computer systemfrom the first transaction computer system; receive, at the secondtransaction computer system, the routing message; identify, using thesecond transaction computer system, a match, at a private matchingvalue, between the first data transaction request and the private datatransaction request, where the private matching value is based on theconstraint value and is different from the requested public matchingvalue and the constraint value; based on identification of the match,transmit a match message back to the first transaction computer system;in response to reception of the match message, perform a process thatconfirms that the match between the first data transaction request andthe private data transaction request is valid; and generate andtransmit, to the first client computer system, a confirmation messagethat includes a public value, which is different from the privatematching value, at which the match occurred between the first datatransaction request and the private data transaction request, whereinthe confirmation does not include the private matching value.
 19. Thenon-transitory computer readable storage medium of claim 18, wherein thestored instructions comprise further instructions that cause thedistributed computer system to: in response to reception of the firstdata transaction request, store, a memory device of the firsttransaction computer system, a reference identifier that acts as aplaceholder for the first data transaction request.
 20. Thenon-transitory computer readable storage medium of claim 18, wherein thestored instructions comprise further instructions that cause thedistributed computer system to: based on identification of the match,lock the private data transaction request such that it cannot bemodified while locked; and in response to reception of an executionconfirmation message sent by the first transaction computer system,unlock the private data transaction request for further processing.